1. Field of the Invention
The invention relates generally to logic testing using a computer program and, more particularly, to rule-based random irritation of a software model of a logic unit under test (UUT).
2. Description of the Related Art
During the design phase of complex logic circuitry such as a microprocessor, such circuitry is broken down into individual units, which must be designed to a specification. Logic designers create these units in a programming language called Hardware Description Language (HDL) such as VHDL, or VHSIC (Very High Speed Integrated Circuit) HDL, based on the specification given to them. But errors might be introduced in the design, causing the unit not to conform to the specification. These errors, or bugs, can cause problems in the unit itself, or propagate errors to other units, causing the processor to be unstable or unusable. The types of errors introduced could be logical errors (e.g., 1+1=3) or errors based on misinterpretation of the specification.
To find these errors, a process of verification is used. Verification is a separate part of the design phase where the units created by the logic designers are tested. A verification engineer's job is to stress the unit to expose situations where the unit does not adhere to its specification.
The actual mechanics of testing logic units can vary. One method is to build a software model of the unit. The model is usually built to conform to a simulator. Typically, such a simulator loads the model and has the capability to stimulate and read any net, such as an internal signal, group of several signals, or input/output pin of the unit, within the model. The type of simulator can be event-driven (the model changes state when a signal changes state) or cycle-based (each connection of the model is evaluated every clock cycle of the simulation).
Once the simulator loads the software model, the model must be stimulated. To accomplish this, a software environment can be used to direct the simulator. The software environment reads a testcase. A testcase is a list of commands to initialize the software test environment, commands for the model, and result information.
During a software model simulation, the software model is loaded into the simulator, and the software environment loads the testcase. The software environment begins parsing the testcase, and when it comes upon a command to be issued to the software model, it sends commands to the simulator to apply stimulus to the model's inputs or to get values from the model's outputs. The software environment then acts on any information it received from the model's outputs to check the state of the software model. This process repeats for every command in the testcase.
When the end of the testcase comes, the software environment usually checks the state of registers, output signals, and/or RAM contents of the model to the expected states of these items provided in the testcase to verify the model ran the testcase correctly. If the state of the software model does not match the expected state given in the testcase, the software environment flags the error.
In order for the software environment to interact with the simulator, an irritator must be created inside the software environment. This irritator must act like the logic unit that feeds the logic unit under test (UUT). Normally, there would be another unit (or units) driving these inputs. Since the unit driving the UUT is not in the model, the software environment must mimic its duties and drive the UUT's inputs.
The input pins of a UUT have a protocol (dictated by the specification) by that any stimulus to them must follow. For example, a UUT has 10 input pins designated as an operand field, 5 input pins for an instruction field, and 30 input pins as a control field, for a total of 55 input pins. The specification says each of these 3 fields has its own rules by which they can be stimulated. In this example, the specification for the UUT indicates that the instruction field has 10 valid values. However, the instruction field of the UUT has 5 pins which translates into 32 different possible values. Since only 10 of the 32 are valid, the verification engineer must ensure this rule is complied with during simulation. Therefore, the irritator for this UUT must ensure that only the 10 valid values of the instruction field are asserted to the 5 instruction field pins of the UUT.
The irritator within the software environment must abide by the specification of the UUT when driving its inputs. If a flaw exists within the irritator, the flaw is inherently passed on to the UUT.
Since the irritator for the UUT must be created by a person, it is open to human errors, just like the logic UUT it is trying to test.
Another problem with the aforementioned method of testing the UUT is that it may take quite a long time to develop an irritator. For most modem microprocessors, the units which make them up are complex, with very exacting specifications. The irritators needed to drive these units can be equally complex. Hence, time spent in developing the irritator is time lost on simulation of the UUT.
Therefore, there is a need for an irritator or an equivalent thereof that is less prone to human errors and takes less time to generate than a conventional irritator.